nicolashofmannshonoursprojectfandomcom-20200214-history
Week8-s2
Objectives final implementation. Progress had an other coursework this week. transformed the groovy code into pure java (long but easy). tryed to make it work on the lego robots. fixed a few mistakes. Then came a very strange bug. The system seemed to block during the first few comunications after the initialisation ad not always the same way. Thouth it could be caused by the absence/limited size of the buffers making the system virtualy out of memory (asexplained in my report). Added buffers (planed to do it for efficiency anyway). Fixed the problem... only most of the time (90%). Messages were arriving to their destination and ack were sended back but seemed to vanish on the way. Thouth that a syncronisation issue may causethe ack to be lost. added a trace mechanism. Noted that synchronisation was fine and that ack were sended on the bluetooth network but not recieved while the stream was correctly fluched. Also noted that trigering the stoping mechanism caused the ack to finally arrive (the ack was therefore not lost but somehow stuck in the bluetooth stack) but also caused the packet to be affected by the same problem afterward. Indirectly knew because of the trace that the ack was sent to the bluetooth layer as soon as receved by the central routing thread (and that it as therefore not the problem) because it was servicing other links correctly which would not have been possible if it was blocked. First added a mechasim to make it possible to me to fluch manually the bluetooth stream. No results. Then added a mechanism to allow me to send a byte and fluch manualy (and modfied the ends to discard the byte when nessesary). It worked. The whole process took me about 10 hours. I concluded that, for some reason, the underlying architecture was sometime returning streams that do not correctly respond to the flush comand since the trace I have clearly indicate that packects could be stuck somewhere between the PC and the NXT. The useless byte I send probably triger the mechaism that automaticaly fluch the buffer when full. Pusching my analisys further to find and fix the source of the problem would require me to inspect the details of the lejos api and potentialy to go deeper in the bluecove library and the bluez stack. I don't have the time for this and have an other way to fix: an useless byte will be automaticaly sent aftereachpacket transmition. Since I'm not sure thatone byte per packet will work (i will test), i may have to add a system that push bytes automaticaly from time to time. The thing will be togelable and set off by default of course. It's dirty but this is the best option I have. After that I would consider the code to be finished and will focus on my report. Supervisor's Comments Ah life is never easy once you try a full test implementation. However you have gone about finding the error in a sensible a scientific manner, which provided you write it up correctly will earn lots of credit. The bluetooth syandard is not well specifiec so it is not surprising that you are finding problems. It could be that with another bluetooth stack/technology the problem would either disappear or be completely different. I agree with your conclusion of get it working and then write up the report!